home *** CD-ROM | disk | FTP | other *** search
/ Columbia Kermit / kermit.zip / newsgroups / misc.19960425-19960715 / 000341_news@columbia.edu _Mon Jul 1 17:12:35 1996.msg < prev    next >
Internet Message Format  |  2020-01-01  |  3KB
  1. Return-Path: news@columbia.edu
  2. Received: from apakabar.cc.columbia.edu (newsmaster.cc.columbia.edu [128.59.35.30]) by watsun.cc.columbia.edu (8.7.5/8.7.3) with ESMTP id RAA14256 for <kermit.misc@watsun.cc.columbia.edu>; Mon, 1 Jul 1996 17:12:34 -0400 (EDT)
  3. Received: (from news@localhost) by apakabar.cc.columbia.edu (8.7.5/8.7.3) id RAA14280 for kermit.misc@watsun; Mon, 1 Jul 1996 17:12:29 -0400 (EDT)
  4. Path: news.columbia.edu!panix!imci5!imci4!newsfeed.internetmci.com!news.uoregon.edu!vixen.cso.uiuc.edu!howland.reston.ans.net!swrinde!ihnp4.ucsd.edu!dog.ee.lbl.gov!news.cs.utah.edu!cc.usu.edu!jrd
  5. From: jrd@cc.usu.edu (Joe Doupnik)
  6. Newsgroups: comp.protocols.kermit.misc
  7. Subject: Re: Local Printing using MS-DOS Kermit
  8. Message-ID: <1996Jul1.095250.82230@cc.usu.edu>
  9. Date: 1 Jul 96 09:52:50 MDT
  10. References: <836224302.23211.0@specialist.co.uk>
  11. Organization: Utah State University
  12. Lines: 35
  13.  
  14. In article <836224302.23211.0@specialist.co.uk>, mark.scott@specialist.co.uk (Mark Scott) writes:
  15. > We have a problem using local printing in MS-DOS kermit.
  16. > 
  17. > We are using standard Vt100 printer escape sequence to direct output
  18. > from PC screen directly to printer port. On which is attached a small
  19. > slip printer. It has DTR connected. The Pc is communicating with a
  20. > UNIX host machine. The objective is to print a file from the host
  21. > machine onto the local printer.
  22. > 
  23. > The problem : For large files sent,  the printed output contains
  24. > corrupted information. (using the PC at the DOS prompt  -   copy <text
  25. > file> >com1  it seems to print the same amount of text to the printer
  26. > ok without corruption. However using the Print command does lead to
  27. > corruption)
  28. > 
  29. > Is there any way in the Kermit set commands to prevent this problem?? 
  30. > ---- Phil
  31. -------------
  32.     MS-DOS Kermit goes to great pains to ensure every byte to be printed
  33. gets to DOS ok. But DOS is handling matters close to the printer. Thus I
  34. suggest you have a careful look at the DOS/Printer part of things, 
  35. particularly flow control (you didn't say whether it's a serial or parallel
  36. port).
  37.     There is another aspect worth thinking about. Printing via terminal
  38. emualtion is totally unguarded. If bytes are lost in transit because the
  39. client machine has interrupts suspended by some non-Kermit process then
  40. at best you get a Control-G replacement byte (if using real serial ports).
  41. A much better tactic is to transfer the file using the Kermit file transfer
  42. protocol, with destination of PRN. That is supposing the remote host side
  43. is configurable to do so.
  44.     And, the "unguarding" comment can be extended to say lack of adequate
  45. flow control along the remote host to Kermit path can lead to lost bytes too
  46. (because DOS is in charge while a buffer is dumped from Kermit to DOS for
  47. printing, and DOS is not very polite about letting the machine run).
  48.     Joe D.